Department of Electrical Engineering and Computer Science
The George Washington University Washington, DC 20052
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)
This project was sponsored by The George Washington University, and in part by the United States Advanced Research Projects Agency (ARPA) under contract #FY3592-93-10234, administered by Phillips Laboratory, Kirtland AFB, NM 87117-5776.
Copyright (C) 1994, Manuel A. Perez and Michael Bliss Feldman
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
GW-Ada/Ed is a development environment built around the New York University (NYU) AdaEd compiler/interpreter. It allows the editing, compiling, binding and execution of Ada 83 programs. GW-Ada/Ed was supervised by Prof. Michael B. Feldman. Manuel A. Perez, a GWU doctoral student in Computer Science, is responsible for the Macintosh version, including the editor and developer shell. We are finishing a good user manual; in the meantime, please bear with this sketchy version. We think the system will be fun to use and as easy to work with as most Mac programs are.
NYU's original README file is included on the disk, for your information.
System requirements - a Mac with a 68030 or 68040 processor, System 7, and at least 4mb of RAM. You should have around 10mb free space on your hard disk, too. We have not tested with System 6 or with a 68020 processor. You are welcome to try, but we make no promises.
We assume in this document that you are relatively familiar with the Mac and how software is installed and run on it.
In the distribution are two self-extracting Stuffit archives, GWAda/Ed.sea and GW-Ada/Ed-Progs.sea. The first contains the system; the second contains a number of interesting demonstration programs: a folder of programs developed at GWU, another set from NYU, and a third from John Dalbey of Cal Poly San Luis Obispo. When you un-stuff these archives, they will create folders will the other files in them. To un-stuff,all you need to do is double-click on the archive icons. You will be given a file-selection dialog to choose where to install the stuff; typically you will install it either in the desktop on at the root level of your hard disk. Install both archives and continue reading this document.
The folder named "GWU AdaEd Folder" contains an application icon "GW Ada"with a version number. This is a double-clickable application. The other files are not. Do NOT move or otherwise disturb these files! GW-Ada/Ed expects to find those files, and behavior will be unpredictable if you mess with them.
1. Double-click on the GW Ada icon, which will put you in the editor. This looks and works like a normal Mac text editor. It is not a word processor; it cannot do formatting of text other than font changes. It can work with multiple open windows, supporting cut, copy, and paste in the usual way.
Opening and compiling a program
-------------------------------
2. From the File menu, select Open, then move through the file-selection dialog until you get into the folder GWU Demos.
3. Select first.ada, opening this file into the editor.
4. From the Develop menu, select Compile. You will be prompted to create a user library, or open an existing one. An Ada library is the place where the compiler puts all its compilation results.
5. Click on New Library. A file selection box opens; just click Create. This will put an Ada library folder into your demo source code folder, which is right where we want it to be. Do NOT move this library folder or try to use the files in it.
6. The compiler will translate your program into Ada/Ed "virtual code", and put the results in your Ada library folder. It will then open a window showing a compilation listing file.
7. You can eliminate the listing file opening each time you compile, by selecting, from the Develop menu, Compile Options. Click on the radio button marked "only if errors are found". If a compilation results in error messages, the listing opens. Otherwise, the listing is just stored in your current (source) directory.
8. From the Windows menu, select Library. This will give you a window showing all the compilation results so far. Notice the entry for subprogram "first", given as an "active" entry.
Linking ("binding") the program
-------------------------------
9. You now need to link this program. "Binding" is what Ada calls the linking process. From the Develop window, select Bind and follow the arrow to FIRST. Selecting this will invoke the binder.
10. Select the library window, and note that there is a new line in the window, mentioning "binding unit FIRST_idle_task". This means that FIRST is now a bound program, ready to execute.
Executing the program
---------------------
11. From the Develop menu, select Execute, then follow the arrow to FIRST. Selecting this will execute the program. The program prompts you for your name, then greets you by name. After execution, just click in the little box to close the console window.
A file called FIRST.OUTPUT will appear in your current folder. This contains all the output from your program execution. In a later release, we will let you exercise more control over this file. For now, you can just delete it if you don't want to keep it. If you run the program a second time, a new file overwrites the first one, so if you wish to keep the old one, you must rename it.
Shortcuts in the Library window
-------------------------------
12. Click on the line "subprogram FIRST" in the Library window. You will see the little Bind button "light up" at the top of the window. Clicking the Bind button will call up the binder.
13. Now double-click on the same line; it will also cause binding to occur.
14. Clicking on a "binding unit" line will light up the Execute button; double-clicking that line will cause execution of the program. Later, when you have lots of library entries, you will find that clicking or double-clicking on package spec or package body lines will have no effect. This is intentional; it is not sensible to bind or execute a package, only a main program!
You are now ready to try the other interesting demo programs in the folder. There is a separate document for this, called GWUDEMOS.DOC, in the demo folder. You can just open this file with the editor and take it from there. You are encouraged to experiment with the tracing options in the Execute Options menu under Develop.
For those who are interested in Ada tasking: Ada/Ed supports tasking quite well, and provides both run-till-blocked and round-robin (time-sliced) task scheduling. This is selected from the Execute Options menu. If round-robin scheduling is enabled, the integer value QuantumSize determines the number of virtual-code instructions executed per slice. If round-robin scheduling seems to be behaving strangely, you can disable it and revert to run-till-blocked scheduling.
The original NYU compiler is generally stable and solid but not perfect. It was government-validated several years ago, which means it passed a large set of fairly stringent tests. The original compiler is not being maintained by NYU; their folks are busy developing a brand-new Ada9X true compiler to be distributed in 1994 as part of the GNU language system. At GW, we are developing the shell and other Ada goodies, but we are not likly to be able to fix bugs in NYU's original code. You can certainly learn a lot about Ada, and, we hope, have a lot of fun, using this system, but it will sometimes fail you. If it does, we're sorry, but that's a part of life in the free-software world. Here are some of the things we know are wrong.
1. Long-running programs, especially tasking programs like Dining Philosophers, may not run for a long time; they may crash sooner, usually on an out-of-memory condition. We think this is due to "memory leakage" in the Ada/Ed system; what is happening is that you are eventually running out of memory. We are working on this problem; it has not been as serious in the Unix and DOS versions of Ada/Ed, so we think it is connected to the memory management we had to figure out when we ported Ada/Ed to the Mac. One way to avoid out-of-memory conditions is to limit your use of dynamic string concatenations; Ada/Ed is known to be rather leaky on these.
2. Source files are limited to 32k. An Ada file larger than this is probably poorly designed and should be split and restructured into smaller files. Compiling really large files gets to be quite slow anyway. Be patient.
3. Keep in mind that the biggest Ada limitation in the NYU Ada/Ed compiler is that the specification of a generic package or subprogram must appear in the same file as the corresponding body. This was a limitation of several early Ada compilers. Ada/Ed-C was developed originally in 1987. We cannot fix this limitation; it is not terribly bothersome but you do have to remember it in developing generics.
4. Occasionally the compiler, especially the first pass, adafront, will quit and give a message referring to an "internal error". If this happens, it means you've stumbled into a bug in the original NYU compiler, which is generally stable and solid but not perfect. Generally, your program is incorrect and confused the translator; you will usually get a listing file to examine the errors. Sometimes even a correct program will cause an internal error. Get in touch with us; send us the Ada source file that caused the crash. We do not have much time or funding to fix NYU's bugs, but we will try. We make no promises, though.
5. If you find bugs in the GW part of the system, namely the editor and "shell", please report them to us, preferably by electronic mail. We will try to fix the bugs or at least suggest a workaround.
